Disaster recovery as a dynamic service

ABSTRACT

A system, method and program product that provides a disaster recovery (DR) brokerage infrastructure. A system is described that includes: a network of intermediate storage nodes and peering points; and a brokerage manager that periodically evaluates a set of DR as a service (DRaaS) providers and selects a cost optimal DRaaS provider for a subscriber, wherein the brokerage manager replicates DR related data for the subscriber in an intermediate storage node prior to delivery to the cost optimal DRaaS provider.

TECHNICAL FIELD

The subject matter of this invention relates to disaster recovery, andmore particularly to a system and method of providing disaster recoveryas a dynamic service on a network infrastructure such as the cloud.

BACKGROUND

Disaster recovery (DR) is a process by which critical aspects of anentity's information technology (IT) environment is replicated at aremote site. In the event of a failure, a failover procedure takes placethat switches IT operations to the remote site to provide operationalcontinuity. Depending on the nature of the operations being performed bythe entity, different levels of disaster recovery may be appropriate.For example, critical operations may need to be up and running veryquickly, while less critical functions can wait.

Two key metrics for measuring recovery plan requirements includerecovery point objective (RPO) and recovery time objective (RTO). RPO isthe maximum period in which data might be lost due to an interruption,while RTO is the time and service level within which a business processmust be restored. A cost benefit analysis is typically used to determinethe aggressiveness of a recovery plan. For example, a business may seekan RPO of 30 minutes and an RTO of 72 hours.

Various network or cloud based DR services are currently available tomeet the particular DR requirements of a given entity. However, currentDR services are essentially static in nature. In other words, once a DRvendor and plan are selected, there is little or no flexibility toeasily change vendors or modify the plan without a significantinvestment of time and resources. Accordingly, there is no simplemechanism for customers to manage DR costs, easily change RPO/RTOtargets, or switch vendors.

SUMMARY

The present disclosure provides a DR service infrastructure in which abrokerage manager dynamically evaluates, selects and changes DR as aservice (DRaaS) providers based on a “best fit” approach. In thismanner, DR is rendered into a modular, open and redundant platform thatloosely couples providers and subscribers. And importantly, the physicaldistance between the subscriber and the DRaaS provider is no longer arestriction for quality of service (QoS), thereby drastically opening upthe DR marketplace for subscribers.

The total cost of ownership (TCO) for DR subscribers is optimizedbecause DR service is transformed into a DR marketplace. The efficiencyof the DR marketplace is increased because a subscriber need not belocked into a particular provider. Moreover, benefits of enhancedutilization accrue because the network backbone of the brokerage managercan be shared across subscribers. Further, because the brokerage fabricis “open,” advanced services such as DR prediction can be readilyintegrated.

A first aspect provides a disaster recovery (DR) brokerageinfrastructure, comprising: a system that provides access to a networkof intermediate storage nodes and peering points; and a brokeragemanager that periodically evaluates a set of DR as a service (DRaaS)providers and selects a cost optimal DRaaS provider for a subscriber,wherein the brokerage manager replicates DR related data for thesubscriber in a selected intermediate storage node prior to delivery tothe cost optimal DRaaS provider.

A second aspect provides a computer program product stored on computerreadable storage medium, which when executed by a computer system,provides a disaster recovery (DR) brokerage infrastructure, comprising:programming instructions for managing a network of intermediate storagenodes and peering points; programming instructions that periodicallyevaluate a set of DR as a service (DRaaS) providers and selects a costoptimal DRaaS provider for a subscriber; and programming instructionsthat manage replication of DR related data for the subscriber in aselected intermediate storage node prior to delivery to the cost optimalDRaaS provider.

A third aspect provides a method of implementing a disaster recovery(DR) brokerage infrastructure, comprising: providing access to a networkof intermediate storage nodes and peering points; periodicallyevaluating a set of DR as a service (DRaaS) providers and selecting acost optimal DRaaS provider for a subscriber; and replicating DR relateddata for the subscriber in a selected intermediate storage node prior todelivery to the cost optimal DRaaS provider.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of this invention will be more readilyunderstood from the following detailed description of the variousaspects of the invention taken in conjunction with the accompanyingdrawings in which:

FIG. 1 shows DR brokerage infrastructure according to embodiments.

FIG. 2 shows a flow diagram of a method of providing DR brokerageservices according to embodiments.

FIG. 3 shows a cloud environment according to embodiments.

FIG. 4 shows further details of a cloud environment according toembodiments.

The drawings are not necessarily to scale. The drawings are merelyschematic representations, not intended to portray specific parametersof the invention. The drawings are intended to depict only typicalembodiments of the invention, and therefore should not be considered aslimiting the scope of the invention. In the drawings, like numberingrepresents like elements.

DETAILED DESCRIPTION

Referring now to the drawings, FIG. 1 depicts a DR brokerage serviceinfrastructure 20 that dynamically links subscribers 24 to DR as aservice (DRaaS) providers 22. As described in this illustrativeembodiment, a brokerage manager 18 dynamically evaluates, selects andchanges DRaaS providers 22 for a subscriber 24 based on the most costoptimal solution. For the purposes of this disclosure, the phrase “costoptimal” may be determined based on any assessment, e.g., financialimpact, time, quality, prior relationships, etc. Accordingly, ratherthan contracting directly with a DRaaS provider 22, the subscriber 24contracts with the DR brokerage service infrastructure 20, which in turnperiodically evaluates available DRaaS providers 22 and selects a bestfit.

DR brokerage service infrastructure 20 generally includes a network ofpeering points 40 and intermediate storage nodes (ISNs) 30, 32, 34.Peering points 40 provide access points through which subscribers 24 andDRaaS providers 22 can connect to infrastructure 20 based on geographicproximity. Peering points 40 also may act as switches for relaying datathroughout the network. ISNs 30, 32, 34 provide storage systems in whichDR related data from a subscriber 24 is temporarily replicated beforebeing loaded to a selected DRaaS provider 22. DR related data generallyincludes information technology (IT) data and information from thesubscriber 24 necessary to implement a DR “failover” in the event thatthe subscriber's primary IT system fails.

Brokerage manager 18 generally includes: (1) a replication orchestrator42 for selecting an ISN 30, 32, 34 for the subscriber and schedulingreplication of the DR related data therein; (2) a candidate selectionsystem 44 that periodically evaluates the set of DRaaS providers 22 andselects the most cost optimal DRaaS provider; (3) a switchover manager46 that manages a process of switching to a new DRaaS provider 22 forthe subscriber 24; and (4) a failover manager 48 that triggers failoverprocedures for the subscriber 24 to the selected DRaaS provider 22 inthe event of an IT failure. Brokerage manager 18 may also include anexternal information manager 50 for receiving external cues to assist infailover decision making.

Accordingly, DR brokerage service infrastructure 20 provides a networkof peering points 40 that carry DR traffic. The ISNs 30, 32, 34 providestorage systems for replicating DR related data from the subscriber'sprimary storage 36, either as full replicas or incremental changes. OnceDR related data is replicated to an ISN 30, 32, 34, it is then furtherreplicated to the selected DRaaS provider 22. By providing peeringpoints 40 near the subscriber 24, the subscriber need not have closeproximity to the DRaaS provider 22 to meet RPO requirements.Furthermore, in situations where both the peering point 40 and selectedISN (e.g., ISN 34) are geographically proximate the subscriber 24,synch-replication of the primary storage may be implemented.

Selection of the ISN 30, 32, 34 may be done in any manner. In oneillustrative embodiment, the ISN 30, 32, 34 is selected based on the RPOrequirements of the subscriber 24. In the current approach, improved RPOis achieved by coupling the feasible modes of data replication to thedistance between the subscriber 24 and the nearest peering point 40,rather than to the distance between the subscriber 24 and the DRfailover site (i.e., DRaaS 22). Once selected, the replicationorchestrator 42 schedules replication of the data into the selected ISNbased on the subscriber requirements.

Candidate selection system 44 evaluates and identifies feasible DRaaSproviders 22 based on the constraints of the subscriber's workload, andthen chooses a DRaaS provider 22 who is the most cost optimal for thesubscriber 24. DRaaS providers 22 may be evaluated periodically forpotential switching, e.g., based on a predetermined time period, basedon a triggering event such as a user request, based on workloadrequirements, etc. A switchover is scheduled from the current DRaaSprovider 22 to a new DRaaS provider 22 if a more cost optimal solutionis available.

Once a decision has been made and scheduled to switch from one DRaaSprovider 22 to another, switchover manager 46 operationalizes theprocess. Timing of the switch may be based on cost variables such ascontractual penalties. Switchover manager ensures the continuous,uninterrupted offloading of DR related data from the subscriber 24 tothe ISN 32 and then to the new selected DRaaS provider 22. Datamigration implemented by the switchover manager 46 may be outsourced toa third party, e.g., when there is a need to switch between DR sitessupporting disparate hypervisors or image formats.

The failover manager 48 is responsible for implementing actual failoverprocedures in the event of an IT failure for a subscriber 24. Failovermanager is also responsible for orchestrating subsequent failbackprocedures to the subscribers system once the failure has been resolved.The candidate selection system 44, switchover manager 46, and failovermanager 48 are threaded asynchronously.

The failover manager 48 may base failover decisions from cues receivedfrom the external information manager 50. Illustrative cues may includeinformation about impending disasters, social media information,financial crisis information, etc. Furthermore, additional ApplicationProgramming Interfaces (APIs) may be provided that subscribers 24 andDRaaS providers 22 can use for programmatic control; and which thirdparty vendors can leverage to provide value-added services.

FIG. 2 depicts a flow diagram showing a method of implementing thedescribed brokerage service with reference to FIG. 1. At S1, a newsubscriber 24 contracts with the brokerage service and connects to theDR brokerage service infrastructure 20 via a nearest peering point 40.At S2, brokerage manager 18 selects an ISN (e.g., ISN 32) based, e.g.,on the specific RPO needs of the subscriber 24. Next at S3, candidateDRaaS providers 22 are evaluated to which one can provide the optimalsolution, e.g., which can meet the workload needs of the subscriber and,of those, select one of the DRaaS providers 22 that can provide the mostcost optimal solution. At S4, DR related data is replicated to theselected DRaaS provider 22 via the ISN 32.

In a first thread at S8, failover manager 48 determines determines if anIT failure has occurred (or might potentially occur). If an IT failureoccurred, failover and failback procedures are implemented with theDRaaS provider for the subscriber 24.

In a second thread, candidate DRaaS providers 22 are re-evaluated todetermine which can provide the optimal solution at S5 and at S6 aperiodic determination is made whether a switch is warranted. If so, aswitchover process is implemented at S7 and replication of data with thenewly selected DRaaS provider 24 at S4.

In the case where subscribers have more relaxed RTO requirements, thefollowing may be implemented. Firstly, the ISN 30, 32, 34 may include aprimary storage pool to ingest incremental data being replicated fromvarious subscribers 24. The replicated data can then be offloaded to asecondary storage pool loosely coupled to the DR brokerage serviceinfrastructure 20, but spatially proximate the selected DRaaS provider22. In this approach, the switchover manager does not provide thestorage replication as part of the DR plan for the selected DRaaSprovider 22. Instead, the failover manager migrates data from thesecondary storage pool to the selected DRaaS provider 22 when a failoveris triggered.

It is understood that although this disclosure includes a detaileddescription that may be utilized to provide cloud-based computingservices, implementation of the teachings recited herein are not limitedto a cloud computing environment. Rather, embodiments of the presentinvention are capable of being implemented in conjunction with any othertype of computing environment now known or later developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g. networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of location independence in that the consumergenerally has no control or knowledge over the exact location of theprovided resources but may be able to specify location at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled and reported providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure comprising anetwork of interconnected nodes. Referring now to FIG. 3, illustrativecloud computing environment 50 is depicted. As shown, cloud computingenvironment 50 comprises one or more cloud computing nodes 11 with whichlocal computing devices used by cloud consumers, such as, for example,personal digital assistant (PDA) or cellular telephone 54A, desktopcomputer 54B, laptop computer 54C, and/or automobile computer system 54Nmay communicate. Nodes 10 may communicate with one another. They may begrouped (not shown) physically or virtually, in one or more networks,such as Private, Community, Public, or Hybrid clouds as describedhereinabove, or a combination thereof. This allows cloud computingenvironment 50 to offer infrastructure, platforms and/or software asservices for which a cloud consumer does not need to maintain resourceson a local computing device. It is understood that the types ofcomputing devices 54A-N shown in FIG. 3 are intended to be illustrativeonly and that computing nodes 11 and cloud computing environment 50 cancommunicate with any type of computerized device over any type ofnetwork and/or network addressable connection (e.g., using a webbrowser).

Referring now to FIG. 4, a set of functional abstraction layers providedby cloud computing environment 50 (FIG. 3) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 4 are intended to be illustrative only and embodiments of theinvention are not limited thereto. As depicted, the following layers andcorresponding functions are provided: Hardware and software layer 60includes hardware and software components. Examples of hardwarecomponents include: mainframes 61; RISC (Reduced Instruction SetComputer) architecture based servers 62; servers 63; blade servers 64;storage devices 65; and networks and networking components 66. In someembodiments, software components include network application serversoftware 67 and database software 68.

Virtualization layer 70 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers71; virtual storage 72; virtual networks 73, including virtual privatenetworks; virtual applications and operating systems 74; and virtualclients 75. In one example, management layer 80 may provide thefunctions described below. Resource provisioning 81 provides dynamicprocurement of computing resources and other resources that are utilizedto perform tasks within the cloud computing environment. Metering andPricing 82 provide cost tracking as resources are utilized within thecloud computing environment, and billing or invoicing for consumption ofthese resources. In one example, these resources may compriseapplication software licenses. Security provides identity verificationfor cloud consumers and tasks, as well as protection for data and otherresources. User portal 83 provides access to the cloud computingenvironment for consumers and system administrators.

Service level management 84 provides cloud computing resource allocationand management such that required service levels are met. Service LevelAgreement (SLA) planning and fulfillment 85 provide pre-arrangement for,and procurement of, cloud computing resources for which a futurerequirement is anticipated in accordance with an SLA. Workloads layer 90provides examples of functionality for which the cloud computingenvironment may be utilized. Examples of workloads and functions whichmay be provided from this layer include: mapping and navigation 91;software development and lifecycle management 92; virtual classroomeducation delivery 93; data analytics processing 94; transactionprocessing 95; and in this case DRaaS.

Referring again to FIG. 1, it is understood that brokerage manager 18may be implemented as a computer program product stored on a computerreadable storage medium. The computer readable storage medium can be atangible device that can retain and store instructions for use by aninstruction execution device. The computer readable storage medium maybe, for example, but is not limited to, an electronic storage device, amagnetic storage device, an optical storage device, an electromagneticstorage device, a semiconductor storage device, or any suitablecombination of the foregoing. A non-exhaustive list of more specificexamples of the computer readable storage medium includes the following:a portable computer diskette, a hard disk, a random access memory (RAM),a read-only memory (ROM), an erasable programmable read-only memory(EPROM or Flash memory), a static random access memory (SRAM), aportable compact disc read-only memory (CD-ROM), a digital versatiledisk (DVD), a memory stick, a floppy disk, a mechanically encoded devicesuch as punch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Python, Smalltalk, C++ orthe like, and conventional procedural programming languages, such as the“C” programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

FIG. 1 depicts an illustrative computing system 10 that may comprise anytype of computing device and, and for example includes at least oneprocessor 12, memory 16, an input/output (I/O) 14 (e.g., one or more I/Ointerfaces and/or devices), and a communications pathway. In general,processor(s) 12 execute program code which is at least partially fixedin memory 16. While executing program code, processor(s) 12 can processdata, which can result in reading and/or writing transformed datafrom/to memory and/or I/O 14 for further processing. The pathwayprovides a communications link between each of the components incomputing system 10. I/O 14 can comprise one or more human I/O devices,which enable a user to interact with computing system 10.

Furthermore, it is understood that the brokerage manager 18 or relevantcomponents thereof (such as an API component, agents, etc.) may also beautomatically or semi-automatically deployed into a computer system bysending the components to a central server or a group of centralservers. The components are then downloaded into a target computer thatwill execute the components. The components are then either detached toa directory or loaded into a directory that executes a program thatdetaches the components into a directory. Another alternative is to sendthe components directly to a directory on a client computer hard drive.When there are proxy servers, the process will, select the proxy servercode, determine on which computers to place the proxy servers' code,transmit the proxy server code, then install the proxy server code onthe proxy computer. The components will be transmitted to the proxyserver and then it will be stored on the proxy server.

The foregoing description of various aspects of the invention has beenpresented for purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdisclosed, and obviously, many modifications and variations arepossible. Such modifications and variations that may be apparent to anindividual in the art are included within the scope of the invention asdefined by the accompanying claims.

What is claimed is:
 1. A disaster recovery (DR) brokerageinfrastructure, comprising: a system that provides access to a networkof intermediate storage nodes and peering points; and a brokeragemanager that periodically evaluates a set of DR as a service (DRaaS)providers and selects a cost optimal DRaaS provider for a subscriber,wherein the brokerage manager replicates DR related data for thesubscriber in a selected intermediate storage node prior to delivery tothe cost optimal DRaaS provider; wherein the brokerage manager includes:a replication orchestrator for determining the selected intermediatestorage node and scheduling replication of the DR related data therein;a candidate selection system that periodically evaluates the set ofDRaaS providers and selects the cost optimal DRaaS provider; aswitchover manager that manages a process of switching to a new DRaaSprovider for the subscriber; and a failover manager that triggersfailover procedures for the subscriber to the selected DRaaS provider inthe event of a disaster incident.
 2. The DR brokerage infrastructure ofclaim 1, where the subscriber and set of DRaaS providers access the DRbrokerage infrastructure via the peering points.
 3. The DR brokerageinfrastructure of claim 1, wherein determining the selected intermediatestorage node is based on at least one of a recovery point objective(RPO) of the subscriber and a purchased service level of the subscriber.4. The DR brokerage infrastructure of claim 1, wherein the candidateselection system: evaluates the set of DRaaS providers based on workloadconstraints of the subscriber; and schedules a switchover if a more costoptimal DRaas provider is identified.
 5. The DR brokerage infrastructureof claim 4, wherein the switchover manager: bases timing of a switchoveron a set of cost variable associated with the switchover; and ensures anuninterrupted flow of DR related data from the subscriber to theintermediate storage nodes and to more cost optimal DRaaS provider. 6.The DR brokerage infrastructure of claim 1, further comprising anexternal information manager for receiving external cues to assist infailover decision making.
 7. A computer program product stored oncomputer readable storage medium, which when executed by a computersystem, provides a disaster recovery (DR) brokerage infrastructure,comprising: programming instructions for managing a network ofintermediate storage nodes and peering points; programming instructionsthat periodically evaluate a set of DR as a service (DRaaS) providersand selects a cost optimal DRaaS provider for a subscriber; programminginstructions that manage replication of DR related data for thesubscriber in a selected intermediate storage node prior to delivery tothe cost optimal DRaaS provider; programming instructions fordetermining the selected intermediate storage node and schedulingreplication of the DR related data therein; programming instructionsthat periodically evaluate the set of DRaaS providers and selects thecost optimal DRaaS provider; programming instructions that manage aprocess of switching to a new DRaaS provider for the subscriber; andprogramming instructions that triggers failover procedures for thesubscriber to the selected DRaaS provider in the event of a disasterincident.
 8. The computer program product of claim 7, where thesubscriber and set of DRaaS providers access the DR brokerageinfrastructure via the peering points.
 9. The computer program productof claim 7, wherein determining the selected intermediate storage nodeis based on at least one of a recovery point objective (RPO) of thesubscriber and a purchased service level of the subscriber.
 10. Thecomputer program product of claim 7, wherein selecting a cost optimalDRaaS provider includes: programming instructions that evaluate the setof DRaaS providers based on workload constraints of the subscriber; andprogramming instructions that schedule a switchover if a more costoptimal DRaas provider is identified.
 11. The computer program productof claim 10, further comprising: programming instructions that basetiming of a switchover on a set of cost variable associated with theswitchover; and programming instructions that ensure an uninterruptedflow of DR related data from the subscriber to the intermediate storagenodes and to more cost optimal DRaaS provider.
 12. The computer programproduct of claim 7, further comprising programming instructions forreceiving external cues to assist in failover decision making.
 13. Amethod of implementing a disaster recovery (DR) brokerageinfrastructure, comprising: providing access to a network ofintermediate storage nodes and peering points; periodically evaluating aset of DR as a service (DRaaS) providers and selects a cost optimalDRaaS provider for a subscriber; replicating DR related data for thesubscriber in a selected intermediate storage node prior to delivery tothe cost optimal DRaaS provider; determining the selected intermediatestorage node and scheduling replication of the DR related data therein;periodically evaluating the set of DRaaS providers and selecting thecost optimal DRaaS provider; switching to a new DRaaS provider for thesubscriber; and triggering failover procedures for the subscriber to theselected DRaaS provider in the event of a disaster incident.
 14. Themethod of claim 13, wherein determining the selected intermediatestorage node is based on at least one of a recovery point objective(RPO) of the subscriber and a purchased service level of the subscriber.15. The method of claim 13, wherein selecting a DRaaS includes:evaluating the set of DRaaS providers based on workload constraints ofthe subscriber; and scheduling a switchover if a more cost optimal DRaasprovider is identified.
 16. The method of claim 15, wherein: timing of aswitchover is based on a set of cost variable associated with theswitchover; and the switchover ensures an uninterrupted flow of DRrelated data from the subscriber to the intermediate storage nodes andto more cost optimal DRaaS provider.
 17. The method of claim 13, furthercomprising receiving external cues to assist in failover decisionmaking.